A Consortium Blockchain-Based Secure and Trusted Electronic Portfolio Management Scheme

In recent times, electronic portfolios (e-portfolios) are being increasingly used by students and lifelong learners as digital online multimedia résumés that showcase their skill sets and achievements. E-portfolios require secure, reliable, and privacy-preserving credential issuance and verification mechanisms to prove learning achievements. However, existing systems provide private institution-wide centralized solutions that primarily rely on trusted third parties to issue and verify credentials. Furthermore, they do not enable learners to own, control, and share their e-portfolio information across organizations, which increases the risk of forged and fraudulent credentials. Therefore, we propose a consortium blockchain-based e-portfolio management scheme that is decentralized, secure, and trustworthy. Smart contracts are leveraged to enable learners to completely own, publish, and manage their e-portfolios, and also enable potential employers to verify e-portfolio credentials and artifacts without relying on trusted third parties. Blockchain is used as an immutable distributed ledger that records all transactions and logs for tamper-proof trusted data provenance, accountability, and traceability. This system guarantees the authenticity and integrity of user credentials and e-portfolio data. Decentralized identifiers and verifiable credentials are used for user profile identification, authentication, and authorization, whereas verifiable claims are used for e-portfolio credential proof authentication and verification. We have designed and implemented a prototype of the proposed scheme using a Quorum consortium blockchain network. Based on the evaluations, our solution is feasible, secure, and privacy-preserving. It offers excellent performance.


Introduction
In recent times, electronic portfolios (e-portfolios) are increasingly used by college or university students and lifelong learners as digital online multimedia résumés that showcase their skill sets and achievements to potential employers when pursuing career opportunities. An e-portfolio [1] is a purposeful collection of digitized samples of work, demonstrations, and artifacts that highlights a person's learning progression and achievements. It serves as evidence of students' capabilities. For example, students can build e-portfolios that present their developed software, research papers, project reports, and multimedia (i.e., audio or video recording interviews or presentations). An e-portfolio can also be used by faculties to monitor and evaluate the effectiveness of educational programs [2][3][4].

Issues and Challenges
E-portfolios require secure, reliable, and privacy-aware credential issuance and verification mechanisms to prove learning achievements. However, with conventional eportfolio systems, it is difficult to systematically prove educational achievements and

•
How can secure, reliable, privacy-preserving e-portfolio credential issuance and verification be enabled? • How can e-portfolio data authenticity and integrity be guaranteed? • How can the blockchain enable learners to own, publish, and manage their e-portfolios while providing recruiters or potential employers the ability to verify the e-portfolio credentials and artifacts in a decentralized fashion?

Contributions
These issues are addressed by designing a decentralized, secure, reliable, and privacypreserving e-portfolio management scheme. This study makes the following contributions:

•
We propose a consortium blockchain-based decentralized, secure, and trusted eportfolio management scheme that is integrated with recruitment platforms. This system provides users with effective methods for sharing their e-portfolios when applying to job opportunities, searching candidate profiles, matching, and recommending services for personalized user experiences.

•
The e-portfolio data is stored in a cryptographically secure and machine-verifiable manner in which the elliptic curve digital signature algorithm (ECDSA) is adopted to guarantee data authenticity and integrity. The blockchain is used to record all the transactions and logs for tamper-proof, trusted e-portfolio data provenance, accountability, and traceability.

•
We have designed and developed smart contracts that empower learners to completely own, publish, and manage their e-portfolios while enabling recruiters or potential employers to verify e-portfolio credentials and artifacts without relying on TTPs. • Decentralized identifiers (DIDs) and verifiable credentials (VCs) are designed and implemented for the proposed scheme following the World Wide Web Consortium (W3C) standard specifications [16][17][18]. DIDs are used for user profile identification, authentication, and authorization, whereas VCs are used for e-portfolio credential proof authentication and verification. • A prototype of the proposed scheme is built using the Quorum blockchain for secure, confidential, quick, and privacy-protected transactions, as well as scalable performance in the consortium network. In addition, we analyzed the privacy and security of the system and provided an evaluation of its performance. The performance is evaluated in terms of computational complexity, transaction latency and throughput, block propagation latency, e-certificate signing, and generation and verification time.
The rest of the paper is organized as follows: Section 2 elaborates on the background and related work. Section 3 describes the proposed scheme. Section 4 provides the system implementation and evaluation details. Section 5 discusses the limitations and open challenges. Section 6 concludes the paper and provides orientations for future research.

Background and Related Work
This section first elaborates on the key concepts of this study that include decentralized identifiers, verifiable credentials, presentations, and claims. Then, it elaborates on the consortium blockchain. Figure 1 presents a definition of the e-portfolio concepts adopted in this study, which is represented using an ontology model. An e-portfolio is completely owned by its holder, and it may have several contributing participants and a verifiable repository that stores relevant artifacts. It is reviewed by qualified experts and is evaluated by an accredited evaluator affiliated with a certified educational institution. The evaluated e-portfolios have associated electronic certificates (known as e-certificates) issued by evaluators; these certificates have a validity period across which they can be used to verify the e-portfolio claims.

Electronic Portfolio Concepts
proof authentication and verification.  A prototype of the proposed scheme is built using the Quorum blockchain for secu confidential, quick, and privacy-protected transactions, as well as scalable perf mance in the consortium network. In addition, we analyzed the privacy and secur of the system and provided an evaluation of its performance. The performance evaluated in terms of computational complexity, transaction latency and throughp block propagation latency, e-certificate signing, and generation and verification tim The rest of the paper is organized as follows: Section 2 elaborates on the backgrou and related work. Section 3 describes the proposed scheme. Section 4 provides the syst implementation and evaluation details. Section 5 discusses the limitations and open ch lenges. Section 6 concludes the paper and provides orientations for future research.

Background and Related Work
This section first elaborates on the key concepts of this study that include decent ized identifiers, verifiable credentials, presentations, and claims. Then, it elaborates on consortium blockchain. Figure 1 presents a definition of the e-portfolio concepts adopted in this study, wh is represented using an ontology model. An e-portfolio is completely owned by its hold and it may have several contributing participants and a verifiable repository that sto relevant artifacts. It is reviewed by qualified experts and is evaluated by an accredi evaluator affiliated with a certified educational institution. The evaluated e-portfol have associated electronic certificates (known as e-certificates) issued by evaluators; th certificates have a validity period across which they can be used to verify the e-portfo claims.

Verifiable Claims
A verifiable claim [16,17] refers to an achievement, qualification, statement, or pi of information regarding an entity that can be verified. It includes an identity, univers degree, or learning achievement. A verified claim is a statement issued by a third pa stating that the claim is true. Typically, a claim describes the properties (i.e., name, qu tity and/or quality, and other characteristics) of an entity that establish its existe uniqueness. An entity (i.e., individual, organization, agent, or device) can make ma kinds of claims. For example, a student can claim an academic degree that proves th capabilities, and an organization can claim access to verify educational records during process of making decisions about job applications.

Verifiable Claims
A verifiable claim [16,17] refers to an achievement, qualification, statement, or piece of information regarding an entity that can be verified. It includes an identity, university degree, or learning achievement. A verified claim is a statement issued by a third party stating that the claim is true. Typically, a claim describes the properties (i.e., name, quantity and/or quality, and other characteristics) of an entity that establish its existence uniqueness. An entity (i.e., individual, organization, agent, or device) can make many kinds of claims. For example, a student can claim an academic degree that proves their capabilities, and an organization can claim access to verify educational records during the process of making decisions about job applications.

Decentralized Identifiers (DIDs)
DIDs are globally verifiable decentralized digital identities that refer to any subject, such as a person, organization, thing, or data model [18]. They can be used by individuals, organizations, and things as globally unique and trusted identifiers in many contexts, such as identification numbers (i.e., college degrees, driver's licenses, or passports). DIDs enable entities to control their identity data and authenticate ownership by verifying cryptographic proof such as digital signatures. A DID is composed of three components: (1) the DID URI scheme, (2) DID method, and (3) DID method-specific identifiers, as shown in Figure 2. The URI scheme indicates the uniform resource identifier scheme, whereas the DID method defines its implementation specifications.

Cryptography Primitives
To create publicly verifiable DIDs and e-certificates, we adopted Ed25519, which is a high-speed and highly secure digital signature scheme [19]. This scheme uses the Ed-wards25519, a twisted Edwards curve for signature generation and verification [20]. The twisted Edwards curve over a prime field, F p [21] is expressed in Equation (1) below: where a, b ∈ F p \{0, 1} with a = d. When a = 1, the curve is known as an Edwards curve (untwisted). Considering a = −1, the curve [21] is expressed as follows: When d = −121,665/121,666 and p = 2 255 −19, the curve is known as Edwards25519, which is the Edwards form of the elliptic curve Curve25519 [22]. A public key, P k (x, y), is generated by multiplying a base or generator point, G, by a secret key, S k . This is referred to as elliptic curve point multiplication (ECPM) [21], which can be defined as follows: where P k is also a point on the curve. It can be computed by adding G to itself S k − 1 times as follows [21]: If S k is expressible as a power of two, P k can be obtained by doubling G on itself log 2 S k times as follows [23]: Algorithm 1 demonstrates the Ed25519 key setup and signature generation process using a secret key, S k , and message, M (i.e., credential or certificate) as inputs. The output of this algorithm is a two-part digital signature. The signature verification mechanism is described using Algorithm 2, in which a message, M, public key, P k , and signature, S, are provided as inputs. The verification result determines whether the given signature is valid or invalid. If the result is true, the message is signed with the exact private key that corresponds to P k and the signature is valid. If the result is false, the signature is invalid because the message is generated with a false private key, which does not correspond to P k . Algorithm 1. Ed25519 key setup and signature generation [20] Curve parameter: G(x, y), a, d, p, order n Input: secret key S k , message M Output: signature S 1: Hash k: h = SHA512(S k ) 2: a = h[0 : 32] 3: a = h[32 : 64] 4: c = SHA512(b M) 5: Interpret a and c as integers in little-endian notation. 6: Compute public key: P k = S k G 7: Generate the first part of signature: R = cG 8: h = SHA512(R P k M) 9: Interpret h as an integer in little-endian notation. 10: Generate the second part of signature: s = (c + ah ) mod n 11: Combine signature pair: S = encode(R) + encode(s) 12: return signature S.

Algorithm 2.
Ed25519 signature verification [20] Curve parameter: G(x, y), a, d, p, order n Input: message M, public key P k , signature S Output: True/False 1: Separate signature pair: R, s = S[0 : 32], decode(S[32 : 64]) 2: h = SHA512(R P k M) 3: Interpret h as an integer in little-endian notation. 4: return sG = R + hQ 2.6. Consortium Blockchain There are two primary types of blockchains, namely permissioned and permissionless blockchains. The former requires prior permission, whereas the latter allows anyone to download the software, join, and operate in the network. A comparative evaluation of five major blockchain platforms [16,[24][25][26][27] is provided in Table 1. Considering the governance approach, we find three types of blockchain networks: public, private, and consortium blockchain networks. Public blockchain networks are open to the public and allow everyone with a copy of the ledger to participate as a node in the decision-making process, whereas private blockchain networks are only open to a group of individuals or participants within an organization. Consortium blockchains (a.k.a. federated blockchains) are hybrid blockchain networks that combine public and private blockchain network features. They are permissioned blockchain networks governed by a group of organizations that have decided to share a ledger among themselves for transactions. However, the topology, roles, and permissions of the participant nodes depend on the network requirements and the blockchain platform-supported protocols. The consortium blockchain has the following advantages [28]: • Access control permission: Permissions at the network and system level are required for nodes and users to join and operate in the consortium blockchain network. A set of roles and various permissions are assigned to each user account and node. • Consensus-driven decentralized governance: The blockchain is governed by the consensus of a set of authorized participating nodes in a decentralized manner. It is easy to manage and enforce the infrastructure's rules and policies. • Low energy and computing resource consumption: The consortium blockchain does not use PoW-like consensus protocols, which consume considerable energy and computing resources when solving complex mathematical puzzles. • Confidentiality and privacy: Consortium blockchains provide support for transaction confidentiality and privacy. They are essential for enterprise blockchain decentralized applications (DApps). • High transaction throughput: Consortium blockchain networks providing high transaction throughput as a consensus on the state of the ledger can be rapidly reached via a set of authorized validator nodes. • Security and scalability: The consortium blockchain provides fault tolerance capability and better protection against disturbances even when nodes behave arbitrarily or maliciously.
In this study, the consortium blockchain is adopted to meet the requirements of our e-portfolio management scheme. These requirements include secure and confidential interactions and data exchange among several participants from several organizations that may not fully trust each other. Table 2 provides a comparison of our proposed scheme with previous studies in the literature. The design of an e-portfolio system for cooperative educational record management using a centralized cloud-based blockchain approach is presented in [29]. Arenas et al. [30] described how permissioned blockchains could be applied to centralized academic credentials issuance and decentralized verification by interested third-party organizations. Though private blockchain-based systems provide private institution-wide solutions that seem to be centralized in some ways, they suffer from SPF issues. Few studies provide decentralized e-portfolio management solutions. Chen and Zhu [31] described an approach for building a decentralized, immutable, secure personal archive management system using a blockchain. Other works [13,14,32] discussed the potential benefits of using blockchains, self-sovereign identity, and digital credentials in the education sector, where educational certification credentials are completely owned and managed by students without requiring any TTPs. However, there still exist several technical challenges that must be overcome to successfully implement these schemes. A design of a blockchain-based eportfolio evaluation system that assesses the education and teaching processes is proposed in [33]. Other studies [34][35][36] presented practical implementations of blockchain-enabled solutions for managing life-long learning achievement records beyond transcripts and certificates. In these systems, learning activities are stored in a blockchain and access rights are managed using smart contracts. Nevertheless, these papers' primary purpose was to investigate how a blockchain of learning logs could be shared across institutions. Furthermore, the identity and certificate issuance schemes in [36] are strictly hierarchical, and they rely on a single accreditation authority that is subject to SPF because of its centralized structure. Thus, if the accreditation authority's private key is leaked or compromised, the entire system will be affected.

Related Work
Recently, [37] proposed a blockchain-based, multilateral personal portfolio authentication scheme that guarantees the reliability, integrity, and transparency of schooling history data. Alexander et al. in [38] investigated how blockchain-enabled smart badges could help learners advance their careers by providing them with personalized recommendation services based on their learning achievements. Blockcerts, a blockchain-based solution for academic credential issuance and verification was introduced in [39]. However, it focuses on eliminating the cost of the degree verification process and did not initially consider the degree issuing institutes. Only the degree certificates issued in digital form were consid-Sensors 2022, 22, 1271 9 of 26 ered, and support for previously issued degree certificates for graduated students was not provided. Docschain [40] tackled the limitations of blockcerts by incorporating the existing degree issuance workflow with features that handle digitized copies of degree documents in optical character recognition (OCR) format. Cerberus [41] was proposed as a blockchainbased accreditation and degree verification solution. It aimed to mitigate credential fraud cases using on-chain smart contracts for credential revocation. However, most previous studies [39][40][41] lack implementation and performance evaluation details. Certain studies [42][43][44][45] introduced authentication, revision, and revocation mechanisms for academic certificate credentials stored on the blockchain to reduce fraud and improve verification efficiency. Nevertheless, most of these solutions do not provide any privacy-preserving e-portfolio management model. As they are built on public blockchain platforms, they have difficulty in ensuring user identity management, confidentiality, and privacy. To reduce the risk of compromising the credentials data, a blockchain-based scheme for self-sovereign identity (SSI) credential sharing with selective disclosure was introduced in [46], which focused on privacy.
Recruitment platform integration; 2 decentralized identifiers/verifiable credentials and verifiable presentations.

Proposed Scheme
This section elaborates on the system design of the proposed scheme, which includes the key stakeholder and role identification, system architecture, cryptography primitives, and system operations.

Key Stakeholder and Role Identification
The following are the key stakeholders of the proposed scheme and their legitimate user roles: • Accreditation authorities certify educational institutions and evaluators by issuing verifiable credentials to them. Accreditation authorities include governments, higher education ministries, and national or international education accreditation agencies. • Certified educational institutions (i.e., colleges, universities, or training centers) provide learning programs, assess learners, and certify learning results and artifacts by issuing cryptographically secure and machine-verifiable e-certificate credentials. • Holders (i.e., students or lifelong learners) completely own, publish, and manage e-portfolios. Portfolio holders possess verifiable credentials, from which verifiable presentations are generated and shared with verifiers to prove ownership. • Evaluators (i.e., accredited professors, instructors, or teachers) assess submitted eportfolio claims and issue and transmit verifiable certificate credentials to the e-portfolio holders. Submitted portfolios can also be peer-reviewed by experts who are seen as certified reviewers. • Verifiers, by receiving verifiable credentials using smart contracts, verify the e-portfolio certificate credential's authenticity and integrity. Examples of verifiers include company recruiters, employers, and higher education supervisors. • Recruitment platforms (i.e., LinkedIn, Indeed, and SaramIn) provide job or internship opportunity postings, candidate profiles searching, matching, and recommendation services. • A verifiable e-portfolio repository is a system that allows users to store, share, and access e-portfolio resources. Verifiable e-portfolio repositories contain publicly, selectively, or privately published verifiable e-portfolio artifacts such as research papers, interview audio or videos, and application source codes. These repositories may require the use of DIDs and verifiable credentials. Examples of verifiable e-portfolio repositories include decentralized databases or distributed ledger-based registries.
Before accessing and operating the system, every user must sign up for a membership user profile with an authorized user role(s) assigned. A DID is generated for each user profile upon registration. Figure 3 provides the workflow of the proposed scheme, which is described as follows: (1) The portfolio holders upload their e-portfolio project artifacts to the e-portfolio repositories, which are protected by private keys for ownership and access control. (2) Subsequently, the portfolio holders create and edit e-portfolio proposals, which can be temporarily saved until their completion. Every e-certificate is digitally signed using the private and public key pair of the evaluator who assessed the corresponding e-portfolio. The public key is encoded in a QR code, which is embedded in the e-certificate and is used for verifying the authenticity and integrity of the e-portfolio credentials. (7) Thereafter, the e-portfolio holders can add or publish the e-portfolio certificates on their recruitment platform profiles, which can be used as evidence of learning achievements and presented to recruiters or potential employers. (8) Verifiers (i.e., recruiters) can search for candidate profiles that match their job requirements. (9) Verifiers can request e-portfolio credentials from the candidate holders for authenticity and integrity verification.

System Architecture
The layered system architecture of the proposed scheme is shown in Figure 4. Aiming at modularity, the system is divided into four layers, which are described below. 1. The secure and trusted e-portfolio management layer provides secure and reliable e-portfolio management features, and it consists of the following modules: (a) The user profile manager is responsible for managing membership enrollments, user profiles, roles, DIDs, and credentials. It is composed of four sub-modules.

System Architecture
The layered system architecture of the proposed scheme is shown in Figure 4. Aiming at modularity, the system is divided into four layers, which are described below.

1.
The secure and trusted e-portfolio management layer provides secure and reliable e-portfolio management features, and it consists of the following modules: (a) The user profile manager is responsible for managing membership enrollments, user profiles, roles, DIDs, and credentials. It is composed of four sub-modules. The security and privacy manager provides custom user security and privacy management functionalities. It comprises the following modules: (a) The security manager provides user credentials and e-portfolio data security-related features such as authentication, authorization, confidentiality, and accountability. (b) The access control manager authorizes or denies access to e-portfolio data depending on the access control policies and rules embedded in the consent agreement contracts [47]. (c) The privacy manager helps users define and manage their privacy preferences, and (d) the audit manager enables users to audit their e-portfolio history in terms of when it was requested and accessed and by whom for verification. The user profile manager and security and privacy manager components extend the generic permissioned features provided by the lower layer. The access control manager authorizes or denies access to e-portfolio data depending on the access control policies and rules embedded in the consent agreement contracts [47]. (c) The privacy manager helps users define and manage their privacy preferences, and (d) the audit manager enables users to audit their e-portfolio history in terms of when it was requested and accessed and by whom for verification. The user profile manager and security and privacy manager components extend the generic permissioned features provided by the lower layer. 2. The blockchain technology and decentralized storage layer provides a consortium blockchain-based immutable transaction distributed ledger and state database, which are maintained via a consensus of authorized peer nodes in the network. This layer provides an operating environment for running smart contracts.
(a) Quorum blockchain [27] has two core components: (a) the Quorum node, which is a forked version of the Go-Ethereum client and is modified to support contract and transaction privacy, and (b) the private transaction manager (PTM), which comprises the transaction manager (TM) and enclave sub-modules. The TM manages private transactions by allowing the access and exchange of encrypted transaction data only between authorized participant nodes. The enclave is a distributed

2.
The blockchain technology and decentralized storage layer provides a consortium blockchain-based immutable transaction distributed ledger and state database, which are maintained via a consensus of authorized peer nodes in the network. This layer provides an operating environment for running smart contracts.
(a) Quorum blockchain [27] has two core components: (a) the Quorum node, which is a forked version of the Go-Ethereum client and is modified to support contract and transaction privacy, and (b) the private transaction manager (PTM), which comprises the transaction manager (TM) and enclave sub-modules. The TM manages private transactions by allowing the access and exchange of encrypted transaction data only between authorized participant nodes. The enclave is a distributed ledger component that independently provides the cryptographic methods used for symmetric key generation, data encryption, and decryption.
The decentralized storage system orchestrates the verifiable e-portfolio repository data storage and access in a distributed or decentralized fashion. It comprises three core components: (a) The API gateway provides application programming interfaces (APIs) to access and interact with the e-portfolio repository; (b) the e-portfolio repository manager manages the e-portfolio repository contents, and (c) the e-portfolio management transactional database (PMS_TDB) is a distributed database used to store the transaction records before being committed and pushed to the blockchain ledger.

3.
The secure communication infrastructure layer provides a secure and reliable communication service based on dedicated legacy Internet secure channels or a novel secure Internet architecture, known as SCION (scalability, control, and isolation on next-generation networks) [48], that enables private paths. Figure 5 depicts the operational working sequence of the proposed scheme. It consists of the three phases described below. ledger component that independently provides the cryptographic methods used for symmetric key generation, data encryption, and decryption.

Working Operations
(b) The decentralized storage system orchestrates the verifiable e-portfolio repository data storage and access in a distributed or decentralized fashion. It comprises three core components: (a) The API gateway provides application programming interfaces (APIs) to access and interact with the e-portfolio repository; (b) the eportfolio repository manager manages the e-portfolio repository contents, and (c) the e-portfolio management transactional database (PMS_TDB) is a distributed database used to store the transaction records before being committed and pushed to the blockchain ledger.
3. The secure communication infrastructure layer provides a secure and reliable communication service based on dedicated legacy Internet secure channels or a novel secure Internet architecture, known as SCION (scalability, control, and isolation on next-generation networks) [48], that enables private paths. Figure 5 depicts the operational working sequence of the proposed scheme. It consists of the three phases described below.

E-Portfolio Creation and Submission
As shown in Figure 5, to register an e-portfolio, the holder creates and submits a new portfolio request that is processed by the system, which returns an e-portfolio proposal. After editing, the holder submits the e-portfolio proposal, which is reviewed and assessed

E-Portfolio Creation and Submission
As shown in Figure 5, to register an e-portfolio, the holder creates and submits a new portfolio request that is processed by the system, which returns an e-portfolio proposal. After editing, the holder submits the e-portfolio proposal, which is reviewed and assessed by specific reviewers and evaluators, respectively. The detailed e-portfolio registration process is provided in Algorithm 3. This algorithm receives the portfolio input parameters P id , P N , τ, ω, ρ, P k , s, δ, ν described in Table 3. Then, it checks if the portfolio ID P id does not exist in the ledger, after which the newPortfolio function is called to execute the transaction that stores a new portfolio instance in the blockchain. Upon successful execution of the transaction, the system emits a newPortfolioCreated event and returns the transaction hash value, which is stored in PMS_TDB. By contrast, in the case of transaction execution failure, an error message is returned, and the smart contract is reverted to its initial state.

Symbol Description
Ca, Aa, SC Smart contract address, account address, smart contract P id , P N, δ E-portfolio identifier, e-portfolio title name, e-portfolio status C id ,C t E-certificate identifier, e-certificate template τ Registration timestamp (date and time) ω E-portfolio creator user profile identifier ρ Evaluator's (i.e., professor or instructor) name P k, S k , S Public key, secret or private key, digital signature s, ν Evaluation score, e-portfolio access URL (uniform resource locator) T h ,QR Transaction hash, quick response code PMS_T DB E-portfolio management system transactional database

E-Portfolio Assessment and Certificate Issuance
Evaluators can accept or reject e-portfolio assessment requests. Upon accepting an assessment request, the evaluator assesses the corresponding e-portfolio submission. Figure 6 depicts the e-portfolio assessment and certificate issuance processes of the proposed scheme. After completing the assessment, the e-portfolio evaluation result is temporarily saved in PMS_TDB, and the holder is notified for confirmation. In the case of an objection, the holder can request a reevaluation. When the evaluation result is confirmed by the holder, the evaluator can confirm and push the result to the blockchain. The e-portfolio certificate is issued only if the evaluation score is higher than or equal to a predefined threshold score value. Algorithm 4 describes the e-certificate issuance process, in which the portfolio and certificate identifiers P id , C id are inputs, and the output is the transaction execution state. First, the system inquires whether the certificate has already been issued for C id by calling the getCertificateInfo function. If no certificate exists for the given C id , then the system determines whether the corresponding e-portfolio P id has been recorded in the blockchain. If P id exists in the blockchain, the portfolio information, P, is collected by calling the getPortfolioInfo function with P id . Finally, a certificate is issued by the system executing a transaction in which P is passed to the issuePortfolioCertificate function of the smart contract.  holder, the evaluator can confirm and push the result to the blockchain. The e-portfolio certificate is issued only if the evaluation score is higher than or equal to a predefined threshold score value. Algorithm 4 describes the e-certificate issuance process, in which the portfolio and certificate identifiers 〈P id , C id 〉 are inputs, and the output is the transaction execution state. First, the system inquires whether the certificate has already been issued for Cid by calling the getCertificateInfo function. If no certificate exists for the given Cid, then the system determines whether the corresponding e-portfolio Pid has been recorded in the blockchain. If Pid exists in the blockchain, the portfolio information, P, is collected by calling the getPortfolioInfo function with Pid. Finally, a certificate is issued by the system executing a transaction in which P is passed to the issuePortfolioCertificate function of the smart contract.

E-Certificate Generation and Verification
The e-certificate generation process is described in Algorithm 5. A proper certificate template Ct (on which the portfolio details will be embedded) is selected based on the portfolio holder's affiliation. The portfolio information, P, is collected by calling the getCer-tificateInfo function with the corresponding Cid. P is signed using the secret key, Sk, of the evaluator (i.e., professor). A QR code that includes the signed P, evaluator's public key,

E-Certificate Generation and Verification
The e-certificate generation process is described in Algorithm 5. A proper certificate template C t (on which the portfolio details will be embedded) is selected based on the portfolio holder's affiliation. The portfolio information, P, is collected by calling the getCertificateInfo function with the corresponding C id . P is signed using the secret key, S k , of the evaluator (i.e., professor). A QR code that includes the signed P, evaluator's public key, P k , and signature, S, is generated. Finally, the portfolio details and QR code are embedded on the template, and later, an e-certificate is created.

Algorithm 5. E-certificate generation
Smart contract parameter: C a , A a Input: C id , S k , P k , C t Output: E-certificate 1: P ← sc.getCertificateInfo(C id ) 2: if E ! = NULL then 3: Generate signature: S = Ed25519.sign(S k , P) 4: Generate QR code: QR = P k , P, S 5: Embed P and QR on C t . 6: else 7: return "No certificate issued for C id ." 8: end if Algorithm 6 demonstrates the e-certificate verification process. To verify an e-certificate, a verifier first extracts the portfolio information, P, public key, P k , and signature, S, from the QR code using a QR code reader. The system checks whether P matches the portfolio details specified on the certificate. If P is the same as the portfolio details written on the certification, then P k is validated using the DID of the corresponding evaluator. If P k is genuine, S is verified using P k . If the verification process succeeds, the certificate is considered to be genuine; otherwise, it is rejected by the system.

Algorithm 6. E-certificate verification
Input: Certificate, evaluator's DID Output: Verification result 1: Read the QR code on the certificate. 2: Extract information P k , P, S from the QR code. 3: if P matches the certificate details then 4: if P k ∈ evaluator's DID then 5: Verify the signature: v = Ed25519.verify(P, P k , S) 6: if v == T rue then 7: return "Certificate is genuine." 8: else 9: return "Invalid signature" 10: end if 11: else 12: return "P k is not genuine." 13: end if 14: else 15: return "Portfolio does not match." 16: end if

Implementation and Evaluation
In this section, we describe the implementation details and provide the privacy and security analysis of our scheme. Finally, the system performance evaluation is provided. Table 4 describes the experiment environment setup used to evaluate the performance of the proposed scheme. The proof-of-concept of our scheme was built using GoQuorum [49], an open-source, Ethereum-based, permissioned blockchain platform with advanced enterprise-grade features that enable contract and transaction privacy, pluggable consensus protocols (i.e., IBFT [50] and RAFT [51]), and scalable performance. A consortium blockchain network infrastructure was deployed in a Docker container environment. This network consisted of six peer nodes and their transaction manager and ethlogger nodes. The network management, monitoring, and reporting tools are described in Table 5. Every peer node has a digital wallet containing the user profile credentials, key pairs, and associated quorum account addresses. Tessera [52] was adopted as a transaction manager to encrypt/decrypt and broadcast private transactions to authorized participant nodes in the consortium blockchain network using Constellation [53], a self-managing and peer-to-peer communication system for secure messaging. The RAFT [51] consensus protocol was adopted for its dynamic on-demand block creation time, fast consensus, and immediate transaction finality. Cakeshop [54] was used to explore, monitor, and manage all the nodes and resources in the consortium blockchain network. In addition, the Cakeshop built-in Sandbox integrated development environment was used to develop, compile, and deploy the smart contracts, which were coded in Solidity language. The JSON-RPC, Web3, and REST APIs were used by a DApp to interact with the smart contracts and blockchain ledger. DApp was developed using Flask, a Python framework for building web applications. A MongoDB server was deployed when implementing the PMS_TDB distributed database.

Privacy and Security Analysis
In this subsection, we analyze various privacy and security features of our system, man-in-the-middle (MITM) attack resilience, and smart contract security.

•
Privacy preservation: To preserve user privacy, the identity and personal information of e-portfolio holders (learners) or evaluators from their learning institutions are not shared across different organizations. Instead, we used DIDs and VCs for user profile identification, authentication, and authorization. Verifiable claims are used for eportfolio credential proof authentication and verification. Furthermore, the proposed solution enables users to define personalized privacy and security settings, which are supported by the underlying permissioned blockchain. • Authentication/authorization and accountability: To access and operate the system, each user must register for a membership user profile with an authorized user role(s) assigned. As all transaction histories are logged in the blockchain-based distributed ledger to ensure traceability, all of the participants are accountable for their activities. GoQuorum [49] provides enhanced network permission models for node and user authentication and authorization. • Data authenticity and integrity: The e-portfolio information recorded on the blockchain cannot be arbitrarily modified because the blockchain is a tamper-proof distributed ledger. To guarantee user credentials and e-portfolio data authenticity and integrity, all the transaction history and logs are saved in the blockchain for its tamper-resistance, trusted data provenance insurance, and accountability features. • Availability and reliability: Conventional certification systems are not publicly verifiable without TTPs, whereas the proposed scheme provides a privacy-preserving selfsovereign e-certificate issuance and verification model that is decentralized, reliable, and secure. Using smart contracts, the verifiers or recruiters can easily validate a certificate by verifying the embedded QR code without interacting with the evaluator or issuing institution. • MITM attack resilience: Making a false claim using a duplicate e-certificate is possible; however, it will not be successful. It is possible to modify the embedded e-portfolio data on the certificate or change the signature. In the case of a duplicate or tampered certificate, the signature cannot be verified by the evaluator's public key because the portfolio information is not signed with the correct evaluator's secret key. The only way to generate an illegitimate e-certificate is to steal the secret key of the corresponding evaluator. Therefore, evaluators are advised to store their secret keys in safe devices. Storing secret keys in insecure devices or sharing the keys with others may create opportunities for unauthorized holders to claim illegitimate e-certificates. • Smart contract security: The security analysis of our solidity smart contracts, which are deployed on the quorum blockchain, was performed using the latest SmartCheck [55] and VeriSmart [56] tools. Smart contracts are secure against well-known vulnerabilities such as integer overflow, integer underflow, access control, unchecked low-level calls, reentrancy attacks, and timestamp manipulation. Furthermore, as quorum eliminated the transaction fees existing in the Ethereum public blockchain, users will never run out of gas [27].

Performance Evaluation
The system performance is evaluated considering the following performance metrics:

Computational Complexity Analysis
We analyzed the computational complexity of core transactions that interact with the blockchain. From Table 6, it can be observed that the complexity of an e-portfolio registration transaction is O(1) corresponding to a single read-write operation. It is necessary to verify whether a given P id portfolio record does not exist in the ledger and then write a new portfolio record instance in the blockchain. However, the e-certificate issuance transaction complexity is O(2), indicating that two read-write operations are required. One read operation collects the e-portfolio details for a given P id , and the other verifies if the given C id certificate does not already exist in the blockchain to avoid duplication. For write operations, one changes the e-portfolio status after its certificate has been issued, and the other records the information from the issued certificate to the blockchain. Finally, the e-certificate verification transaction complexity is O(1), which consists of a single read-write operation. This operation verifies the e-certificate authenticity and validity of a given C id and logs the verification result in the blockchain. As the transaction's algorithm complexity affects its execution time and latency, the evaluation results reveal that the computational complexity of the proposed algorithms is linear and increases linearly with the size of the input transactions. Table 6. Computational complexity of the core transactions interacting with the blockchain (read operation: RO, write operation: WO).

Transaction Type
RO WO

E-Portfolio Transaction Latency and Throughput
The transaction latency is the time that elapses between a transaction request submission and the response after the transaction is successfully executed, confirmed and included in a block, and committed to the blockchain [27]. By contrast, the transaction throughput is the number of transactions processed per second (TPS) by the blockchain network. In this experiment, we aimed to analyze the impact of input transaction rates on the transaction latency and throughput of the blockchain network. We generated mixed input transaction workloads (read and write) ranging from 1 to 2000 tx/s to test the system's response to stress. The experiment was repeated three times, and then the average latency and throughput of the transactions were calculated. Table 7 provides the performance values of the e-portfolio registration transaction. In Figure 7a, we assessed the e-portfolio registration transaction latency performance under variable input transaction rates. An e-portfolio registration transaction with a size of 2.380 KB takes 164.677 ms to be processed, included within a block, and committed to the blockchain. It is found that the transaction latency scales linearly as the input transaction rate increases. Figure 7b shows the throughput measurements for the e-portfolio registration and e-certificate issuance transactions. For both transactions, the throughputs scale linearly with the low transaction input rates at approximately 132 tx/s and 363 tx/s for the e-portfolio registration and e-certificate issuance transactions, respectively. Nonetheless, the throughput does not increase considerably until a maximum of 140 tx/s and 370 tx/s for the e-portfolio registration and e-certificate issuance transactions, respectively. operation. This operation verifies the e-certificate authenticity and validity of a given Cid and logs the verification result in the blockchain. As the transaction's algorithm complexity affects its execution time and latency, the evaluation results reveal that the computational complexity of the proposed algorithms is linear and increases linearly with the size of the input transactions.

E-Portfolio Transaction Latency and Throughput
The transaction latency is the time that elapses between a transaction request submission and the response after the transaction is successfully executed, confirmed and included in a block, and committed to the blockchain [27]. By contrast, the transaction throughput is the number of transactions processed per second (TPS) by the blockchain network. In this experiment, we aimed to analyze the impact of input transaction rates on the transaction latency and throughput of the blockchain network. We generated mixed input transaction workloads (read and write) ranging from 1 to 2000 tx/s to test the system's response to stress. The experiment was repeated three times, and then the average latency and throughput of the transactions were calculated. Table 7 provides the performance values of the e-portfolio registration transaction. In Figure 7a, we assessed the eportfolio registration transaction latency performance under variable input transaction rates. An e-portfolio registration transaction with a size of 2.380 KB takes 164.677 ms to be processed, included within a block, and committed to the blockchain. It is found that the transaction latency scales linearly as the input transaction rate increases. Figure 7b shows the throughput measurements for the e-portfolio registration and e-certificate issuance transactions. For both transactions, the throughputs scale linearly with the low transaction input rates at approximately 132 tx/s and 363 tx/s for the e-portfolio registration and ecertificate issuance transactions, respectively. Nonetheless, the throughput does not increase considerably until a maximum of 140 tx/s and 370 tx/s for the e-portfolio registration and e-certificate issuance transactions, respectively.

Block Propagation Latency
GoQuorum [49] supports fault-tolerant consensus protocols, such as RAFT and IBFT. The block creation and validation are guaranteed, as the network can still operate and reach consensus even in the presence of adversary nodes. With RAFT, blocks are minted on-demand no more frequently than every 50 ms [51]. RAFT offers faster block times and does not create unnecessary empty blocks, whereas, with IBFT, blocks are always minted by validators at regular intervals, even in the absence of transactions on the network [50]. The IBFT block time is by default 1 s. The block propagation latency is the average time taken for a block to be produced and broadcast throughout the blockchain network [27]. As the block time parameter affects the overall latency and throughput of the system, we investigated the impact of the input transaction rates on the block propagation latency. The number of transactions per block is set by default to one for simplicity. The e-portfolio registration transaction block size is 4.251 KB, and the propagation latency is on average 1.081 ms, as indicated in Table 7. Nevertheless, the e-certificate issuance transactionrelated block size is 4.768 KB with 1.705 ms of propagation latency, as given in Table 8. Figure 8 shows the block propagation latency measurements for e-portfolio registration and e-certificate issuance transactions. The block propagation latency scales as the number of input transactions increases. However, the network exhibits, on average, a 36.59% lower block propagation latency for e-portfolio registration transactions when compared to e-certificate issuance transactions. Figure 7. Transaction latency and throughput: (a) e-portfolio registration transaction latency measurements with variable input transaction rates; (b) e-portfolio registration and e-certificate issuance transaction throughput measurements with variable input transaction rates. GoQuorum [49] supports fault-tolerant consensus protocols, such as RAFT and IBFT. The block creation and validation are guaranteed, as the network can still operate and reach consensus even in the presence of adversary nodes. With RAFT, blocks are minted on-demand no more frequently than every 50 ms [51]. RAFT offers faster block times and does not create unnecessary empty blocks, whereas, with IBFT, blocks are always minted by validators at regular intervals, even in the absence of transactions on the network [50]. The IBFT block time is by default 1 s. The block propagation latency is the average time taken for a block to be produced and broadcast throughout the blockchain network [27]. As the block time parameter affects the overall latency and throughput of the system, we investigated the impact of the input transaction rates on the block propagation latency. The number of transactions per block is set by default to one for simplicity. The e-portfolio registration transaction block size is 4.251 KB, and the propagation latency is on average 1.081 ms, as indicated in Table 7. Nevertheless, the e-certificate issuance transaction-related block size is 4.768 KB with 1.705 ms of propagation latency, as given in Table 8. Figure 8 shows the block propagation latency measurements for e-portfolio registration and e-certificate issuance transactions. The block propagation latency scales as the number of input transactions increases. However, the network exhibits, on average, a 36.59% lower block propagation latency for e-portfolio registration transactions when compared to e-certificate issuance transactions.    Figure 9a, we analyzed the e-certificate issuance transaction latency using variable input transaction rates. The results show that the total e-certificate issuance transaction latency scales linearly as the input transaction rate increases. Furthermore, the e-certificate signing time and the generation time are 0.55% and 65.27% of the total issuance latency time, respectively. In Figure 9b, we evaluated the ecertificate verification time using a variable number of input certificate verification requests. The verification request transaction time measurements exhibit a linear progression that is proportional to the number of input certificates. The average time needed to verify the Ed25519 signature embedded in the QR code for each certificate is 136.071 ms.   Figure 9a, we analyzed the e-certificate issuance transaction latency using variable input transaction rates. The results show that the total e-certificate issuance transaction latency scales linearly as the input transaction rate increases. Furthermore, the e-certificate signing time and the generation time are 0.55% and 65.27% of the total issuance latency time, respectively. In Figure 9b, we evaluated the ecertificate verification time using a variable number of input certificate verification requests. The verification request transaction time measurements exhibit a linear progression that is proportional to the number of input certificates. The average time needed to verify the Ed25519 signature embedded in the QR code for each certificate is 136.071 ms.

Limitations and Open Challenges
Our blockchain-enabled secure and trusted e-portfolio management system could act as an anti-counterfeiting digital twin to ensure that portfolio data has not been tampered with. However, blockchain security [55][56][57][58][59][60] still imposes substantial challenges that require further research. These challenges occur at four levels:

Process Level
(a) Smart contract vulnerabilities: As smart contracts are leveraged to automate processes, they must be correctly coded and systematically verified to ensure that they can run accurately without bugs and security vulnerabilities before deployment. In addition, smart contracts are immutably stored on the blockchain after deployment and cannot be updated or upgraded to patch bugs or security vulnerabilities. Smart contract security [55][56][57][58] is a serious issue that must be considered in terms of the entire system lifecycle from requirement analysis to coding, deployment, and maintenance. (b) Privacy and security policies: Users must define adequate privacy and security policies to protect their resources. This process might be challenging if the system does not provide sufficient support. (c) Operation standards and regulations: Operational and regulatory standards are required for a massive adoption of blockchain technology in education for lifelong records keeping and self-sovereign credentials issuance and verification.

Data Level
Blockchain security [58] at the data level includes access control, key management, encryption, and consensus algorithms.
(a) Access control and key management: Efficient access control mechanisms are required for authentication and authorization. User-friendly cryptographic key management schemes are needed to confidentially encrypt and decrypt user data. (b) Blockchain oracle: The data exchange between the off-chain and on-chain environment is enabled by smart contracts, which must be properly integrated within DApps to avoid the blockchain oracle issue [59]. (c) Consensus algorithms: Robust and fault-tolerant consensus mechanisms are critical for data synchronization among participating nodes and to maintain the consistency of the ledger.

Infrastructure Level
(a) Standardization: Standards are essential for enabling the resolution, authentication, and interoperability of DIDs and VCs across various domains over the Internet. Cryptographic keys are essential for creating the digital signatures used to verify user identity and prevent data tampering. (b) Organization, node, and account permissions: The consortium blockchain should support enhanced permission features at the network, organization, node, account, and resource levels depending on business needs. Organizations should be able to create sub-organizations and assign roles to their nodes and accounts. Private contracts and transactions should be visible and accessible only to authorized users. (c) Blockchain network and communication infrastructure security: Although the proposed scheme has leveraged smart contracts and a distributed ledger to enable decentralization, in some cases, integrated recruitment platforms and/or verifiable repository services (e.g., GitHub or Google Drive) may still be centralized; these services may be targeted by distributed denial-of-service (DDoS) attacks to render e-portfolio resources unavailable. However, this vulnerability can be mitigated using a secure and highly available Internet architecture like SCION [48], which provides secure multi-communication paths that cannot be hijacked and guarantees communication despite DDoS attacks. The blockchain security issues [60] also require further research.

Physical Level
As the identity and/or certificate information on a document can be forged before being recorded in the blockchain, tamper-resistant chemical signatures (in addition to the physical QR code) may be useful for physical certificate counterfeiting prevention in a distributed context, as proposed in [60].

Conclusions and Future Research
In this study, we have designed and implemented a decentralized, secure, and reliable e-portfolio management scheme powered by a consortium blockchain. Smart contracts were leveraged to enable learners to design, own, publish, and control their portfolios over a lifetime of learning and work. Furthermore, the e-portfolio credentials and artifacts are verifiable by potential employers and recruiters without relying on trusted third-party support. The immutable blockchain-enabled shared ledger records the complete transaction history to provide accountability, traceability, and tamper-resistant trusted data provenance. The reliability and decentralization promoted by the blockchain guarantee the long-term availability of e-portfolio resources for holders and investors. In addition, to preserve user privacy, DIDs are used to identify, authenticate, and authorize user profiles, whereas VCs enable e-portfolio credential proof authentication and verification. We analyzed the system privacy and security, and evaluated its performance considering the computational complexity, latency, and throughput of transactions; block propagation latency; e-certificate signing; and generation and verification time. The evaluation results demonstrate that our proposed scheme is feasible and secure, protects user privacy, and exhibits superior performance. This study is a step towards smart self-sovereign e-portfolio management as well as secure and reliable educational data exchange both nationally and internationally. However, there still remain non-technical challenges such as operation standardization, governance, and regulation. Future research directions are as follows:

•
We plan to investigate recommended algorithms for providing efficient matches between learners and educators through online education platforms and between job seekers and employers through trusted skill marketplaces. • Automated tools for auditing and fixing smart contract vulnerabilities are essential for ensuring system security at the process level.

•
The design of user-friendly and efficient key management approaches would enable users to take advantage of our proposed solution.